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Disclaimer 


The information in this document is provided as is and no guarantee or warranty is 
given that the information is fit for any particular purpose. The user thereof uses the 
information at its sole risk and liability. 


The document reflects only the authors’ views and the EC is not liable for any use 
that may be made of the information contained therein. 
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Executive summary 


The loT European Platforms Initiative (IoT-EPI) projects are address- 
ing the topic of Internet of Things and Platforms for Connected Smart 
Objects and aim to deliver an loT extended into a web of platforms 
for connected devices and objects that supports smart environments, 
businesses, services and persons with dynamic and adaptive configu- 
ration capabilities. The specific areas of focus of the research activities 
are architectures and semantic interoperability, which reliably cover 
multiple use cases. The goal is to deliver dynamically-configured in- 
frastructure and integration platforms for connected smart objects 
covering multiple technologies and multiple intelligent artefacts. The 
ІоТ-ЕРІ ecosystem has been created with the objective of increasing 
the impact of the loT-related European research and innovation, in- 
cluding seven European promising projects on loT platforms: AGILE, 
BIG loT, INTER-loT, VICINITY, SymbloTe, bloTope, and TagltSmart. 

This white paper provides an insight regarding interoperability 
in the loT platforms and ecosystems created and used by loT-EPI. The 
scope of this document covers the interoperability aspects, challeng- 
es and approaches that cope with interoperability in the current ex- 
isting loT platforms and presents some insights regarding the future 
of interoperability in this context. It presents possible solutions, and a 
possible loT interoperability platform architecture. 
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Due to the critical and important role of interoperability in loT 
systems, It is strongly related with many relevant topics and aspects 
in loT: performance, compatibility, integration, ROI, market accep- 
tance, development design, architecture. 

The creation and development of this white paper has taken ad- 
vantage from outcomes and available information from other activi- 
ties in the framework of the loT-EPI projects. In particular, important 
sources of information that complement the authors' research are the 
Io T-EPI platforms reports and the exchange of information among the 
projects during the work in task forces. 

Regarding the output of this work, this white paper intends to be 
a useful source of information of interoperability in loT platforms. This 
critical aspect in loT systems has relevance and impact on the topics 
of each Task Force of the Io T-EPI (Innovation, Platform Interoperability, 
Community Building, Business Models, Educational Platforms, Inter- 
national Cooperation). 

The research regarding interoperability architecture is useful for 
the current and future loT platforms and loT projects, as it provides 
deep awareness and valuable insights regarding the critical aspect of 
interoperability in them, as well as possible architecture solutions to 
the challenges that the achievement of platform interoperability in- 
volves. This information can be valuable in the development of new 
services, applications and businesses on top of loT platforms. 

Lack of platform interoperability causes major technologic and 
economic drawbacks such as impossibility to plug non-interoperable 
loT devices into heterogeneous loT platforms, impossibility to develop 
loT applications exploiting multiple platforms, slowness of loT tech- 
nology introduction at a large-scale, discouragement in adopting loT 
technology, vertical silos in loT ecosystems and markets, increase of 
costs, scarce reusability of technical solutions, or user dissatisfaction. 

In contrast, interoperability among platforms will provide numer- 
ous benefits such as new market opportunities, the disappearance of 
vertical silos, and vertically-oriented closed systems, architectures 
and application areas, to move towards open systems and platforms, 
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and a major cooperation among platforms to offer better solutions to 
the consumer and the users. The cross-availability of services and 
data will allow current service providers to reach new markets with 
their services, but perhaps, more importantly, we expect new busi- 
ness opportunities to emerge from the ability to manage data from 
diverse sources to create innovative solutions. 


Taylor & Francis 
Taylor & Francis Group 


http://taylorandfrancis.com 


loT platforms landscape 


Definitions 


An loT platform can be defined as an intelligent layer that connects 
the things to the network and that abstracts applications from the 
things with the goal to enable the development of services. loT plat- 
forms achieve several main objectives such as flexibility (being able 
to deploy things in different contexts), usability (being able to make 
the user experience easy) and productivity (enabling service creation 
in order to improve efficiency, but also enabling new service devel- 
opment). An loT platform facilitates communication, data flow, device 
management, and the functionality of applications. The goal is to build 
loT applications within an loT platform framework. An loT platform 
allows applications to connect machines, devices, applications, and 
people to data and control centres [1]. 

loT platforms’ functionalities cover the digital value chain from 
sensors/actuators, hardware to connectivity, cloud and applications, 
as illustrated in Figure 2.1. Hardware connectivity platforms are used 
for connecting the edge devices and processing the data outside the 
datacentre (edge computing/fog computing), and program the devices 
to make decisions on the fly. The key benefits are security, interoper- 
ability, scalability and manageability by using advanced data manage- 
ment and analytics from sensor to datacentre. loT software platforms 
include the integration of heterogeneous sensors/actuators; various 
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Figure 2.1. loT Platforms covering the data value chain [1] 


communication protocols abstract all those complexities and present 
developers with simple APIs to communicate with any sensor over 
any network. 

loT platforms also assist with data ingestion, storage, and an- 
alytics, so developers can focus on building applications and ser- 
vices, which 15 where the real value lies in loT. Cloud-based loT 
platforms are offered by cloud providers to support developers 
to build loT solutions on their clouds. Infrastructure as a Service 
(laaS) providers and Platform as a Service (PaaS) providers have 
solutions for loT developers covering different application areas. 
PaaS solutions, abstract the underlying network, compute, and 
storage infrastructure, have focus on mobile and big data function- 
ality, while moving to abstract edge devices (sensors/actuators) 
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and adding features for data ingestion/processing and analytics 
services [1]. 

loT platform definitions may differ in subtle and perhaps sec- 
ondary details while overlapping on major features. One of the most 
succinct definitions of an loT platform has been proposed by Gartner 
[2]. It defines the loT platform as a software suite or a PaaS cloud 
offering that monitors, and may manage and control, various types 
of endpoints, often via applications end users build on the platform. 
It facilitates operations involving loT endpoints and integration with 
enterprise resources. Platforms should be capable of: 


e Provisioning and management of devices and their application 
software 

e Data aggregation, integration, transformation, storage and 
management (often collectively referred to as “data digestion’) 

e Event processing (rule engine/orchestration/BPM) 

e Customizing and building applications (SDK, app server, IDE 
and others) 

e [оТ data analysis and visualization 

e Cybersecurity 

e [оТ device communications (network and/or Internet) 

e Adapter (API hub, gateway software but also to the application 
on endpoint) 

e User interfaces for both end users and developers 


loT platforms facilitate communication, data flow, device man- 
agement, and the functionality of applications. A platform is not the 
application itself, although many applications can be built entirely 
within an loT platform framework. It links machines, devices, ap- 
plications, and people to data and control centres. It is not confined 
to brick-and-mortar central command: ideally, it can be accessed 
and managed from many different locus points. It employs better, 
quicker search engines and data storage systems with the capacity 
and sophistication to handle volume far beyond what has brought 
industry to the present moment [3]. Most of its elements are cloud- 
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based and running on wireless connectivity, which may be estab- 
lished via third-party providers, application programming interfaces 
(APIs), cellular capabilities, or -most likely- a combination of these 
technologies. 

Through dashboards, APIs, data engines, and algorithms, a plat- 
form enables elements and sectors of a business network to connect, 
monitor, and communicate with each other with far greater speed and 
flexibility than we have yet seen. Data from an ever-expanding eco- 
System can be collected, sorted, and harnessed entirely online. The 
platform also can enable data prioritization, a feature of critical im- 
portance at a time when machines, sensors, and other objects are 
beginning to generate new floods of information. 

loT platforms provide security features, scalability, and capacity 
for pulling in, storing, and analysing data. It may connect machines, 
people, applications, or all three. Like any intelligent network, it pro- 
vides innate predictive qualities that use data for the purposes of 
maintenance and troubleshooting. The user interfaces are intuitive 
and extensible, allowing for the future development of application ex- 
tensions and the necessary scalability to track an increasing number 
of connected devices, people, and data sources. 

Essentially, an loT platform allows for greater concentration of 
resources in value-added applications. Instead of requiring compa- 
nies to focus on the lower levels of the technology stack, which are 
essential but not value-positive, attention can be paid to application 
development; a smarter, more integrated loT ecosystem; and intelli- 
gent data generation. 

Using loT platforms applications are sent to market faster and 
with better support. Connectivity and data management - which his- 
torically have required huge investments in time and development 
costs - are “givens” on the loT platform, as reliable as electricity gen- 
eration, and just as liberating to users. 

The root of the loT is connectivity: more things, more people, and 
the matrix of connections that springs up between them. Yet, in less 
than a decade, the technology has moved far beyond this fundamen- 
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tal consideration. Where many companies may have believed it was 
advantageous to build out a platform internally, it is becoming clear 
that much of the technology stack can now be implemented with out- 
of-the box tools and effective engagement with vendors. 

ThingWorx [4] defines an loT platform as a suite of components 
that enable: 


• Deployment of applications that monitor, manage, and control 
connected devices. 

e Remote data collection from connected devices. 

* Independent and secure connectivity between devices. 

* Device/sensor management. 

* Integration with third party systems. 


loT platforms exist independently between the hardware and the 
application layers of the loT technology stack. The ideal platform will 
integrate with any connected device, blend in with device applications, 
and enable implementation of loT features and functions into any de- 
vice in the same way. 

Link Labs [5] defines an loT platform at a high level as "the sup- 
port software that connects edge hardware, access points, and data 
networks to other parts of the value chain (which are generally the 
end-user applications). loT platforms typically handle ongoing man- 
agement tasks and data visualization, which allow users to automate 
their environment. You can think of these platforms as the middleman 
between the data collected at the edge and the user-facing SaaS or 
mobile application”. 

loT platforms are often referred to as middleware solutions, 
which can collectively be referred to as the value chain of loT, that are 
the “plumbing” of the loT. Generally, an loT or M2M solution is a mash- 
up of functions from multiple vendors, which include: 


e Sensors or controllers. 
* А gateway device to aggregate and transmit data back and 
forth to the data network. 
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e A communications network to send data. 
e Software for analysing and translating data. 
e The end application service, which creates much of the value. 


loT platforms interoperability 
concepts, approaches and 
principles 


Achieving interoperability is one of the main objectives of the loT. As 
the name Internet of Things already states, it is all about connecting 
things and make them easily accessible just like the Internet today. 
"Broadly speaking, interoperability can be defined as a measure of 
the degree to which diverse systems, organizations, and/or individu- 
als are able to work together to achieve a common goal" [6]. However, 
interoperability is a complex thing and there are many aspects to it. In 
literature, there exists quite a lot of different classifications of these 
aspects of interoperability, often also called levels of interoperability. 
One of the most important classification of levels of interoperability 
for technical systems is called Levels of Conceptual Interoperability 
Model (LCIM) and is depicted in Figure 3.1. Although it was created 
in the context simulation theory it has a much broader applicability. 
It defines six levels of interoperability: technical, syntactic, semantic, 
pragmatic, dynamic and conceptual interoperability. 

The European Interoperability Framework designed “to support 
the delivery of pan-European eGovernment services to citizens and 
enterprises" [8] defines only three levels: technical, semantic and or- 
ganisational interoperability. 
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Figure 3.1. The Levels of Conceptual Interoperability Model [7]. 


A more loT-specific classification is provided by ETSI and AIOTI 
and defines four levels [9]: technical, syntactic, semantic and organi- 


sational interoperability. In short, they are defined as follows. 


e Technical Interoperability: usually associated with communi- 


cation protocols and the infrastructure needed for those pro- 


tocols to operate. 


e Syntactic Interoperability: usually associated with data for- 


mats and encodings, e.g., XML, JSON and RDF. 


• Semantic Interoperability: associated with the common un- 


derstand of the meaning of the exchanged content (informa- 


tion). 


* Organisational Interoperability: associated with the ability of 


organisations to effectively communicate and transfer infor- 
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mation even across different information systems, infrastruc- 
tures or geographic regions and cultures. 


As this is the most agreed-upon classification of interoperability 
levels within the loT domain we follow it in this document. 


loT platforms interoperability challenges 


3.1.1. Patterns of loT interoperability 


Achieving interoperability on the loT, requires a closer look at inter- 
actions of the key components tn loT ecosystems. Before looking into 
the specifics of technical interoperability, syntactic interoperability, 
semantic interoperability, and organizational interoperability, we anal- 
yse here those interactions and we identify in Figure 3.2 six generic 
interoperability patterns for loT ecosystems. This subsection is based 
on the material published in [10]. 

The "Cross Platform Access” pattern (Figure 3.2, 1) is the basic 
characteristic of an interoperable loT ecosystem. The goal of this pattern 
is to hide that an application or service accesses resources (informa- 
tion or functions) from different platforms through the same interface 
specification. The challenge of realizing this goal lays in allowing appli- 
cations or services to discover platforms with relevant information, and 
enabling platforms that are potentially from different providers to have 
the same interface and use the same formats to communicate data. 

The pattern "Cross Application Domain Access” (Figure 3.2, II) ex- 
tends the "Cross Platform Access” pattern. The goal is that services/ 
applications are able to access information and functions not only 
from different platforms, but also from platforms, which host infor- 
mation from multiple application domains. Thereby, it is crucial that 
semantic interoperability is given through well-defined and shared 
information models. A cross-domain application that accesses multi- 
ple loT platforms, could e.g. air quality information and traffic data to 
provide green routing through a city. 
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Figure 3.2. The patterns of interoperability [10]. 
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The goal of the pattern “Platform Independence” (Figure 3.2, III) 
is to allow a single application or service to be used on top of differ- 
ent loT platforms (e.g. in different regions). For example, these can be 
multiple deployments of a “smart parking” service used in two differ- 
ent geographic regions, which utilize different platforms with infor- 
mation about parking spots. This is especially challenging, when the 
sensors producing the loT data are based on entirely different tech- 
nology (e.g., radar-based parking spot observation, or counting in and 
outs of a parking lot). 

The goal of the “Platform-Scale Independence” pattern (Figure 
3.2, IV) is to hide different platform scales towards the connecting ser- 
vices and applications. The so called server-level platforms are plat- 
forms with many devices connected (e.g. a cloud platform), whereas 
device-level platforms grant direct access to attached sensors, and 
fog-level platforms are intermediaries such as edge gateways. A plat- 
form implementing this pattern has to hide its scale from applications 
and services accessing it. 

Finally, the pattern “Higher-level Service Facades” (Figure 3.2, 
V) extends the interoperability requirements from platforms to high- 
er-level services. Here, services are acting similar to platforms and 
also provide loT offerings via a common interface. Such a service acts 
as a facade towards an loT platform and use or process the loT offer- 
ings of the platform to provide added value. 

Once the above described patterns are implemented, they en- 
sure ecosystem interoperability and allow an easy re-usage of loT of- 
ferings from the various platforms of the ecosystem. 

Organizational interoperability can be realized by loT platform 
federations formed by multiple partnering institutions that collab- 
orate by sharing loT resources in locations originally out of their 
reach. This represents an additional horizontal integration that en- 
ables "Open networked" loT business models according to the clas- 
sification in [11]. 

We can define an loT platform federation as an association of 
several platforms enabling their secure interoperation, collabora- 
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tion and sharing of resources. Platforms can be enabled to perform 
collaborative sensing/actuation tasks and to interact directly so as 
to trade/share resources. A mechanism for defining and monitor- 
ing Service Level Agreements (SLAs) should be in place, while we 
can also envision the emergence of roaming loT devices, where a 
device registered and managed by one platform is nomadic and 
can interact with resources in smart spaces managed by another 
federated platform (in a visited smart space). Federated platforms 
should of course control the terms under which a roaming loT de- 
vice is allowed to use resources in environments operated by vis- 
ited platforms. 

Platform-to-platform direct interactions enable existing (native) 
applications to use resources managed and operated by other feder- 
ated platforms as if they were offered by a single platform, as shown 
in Figure 3.2.VI. This reduces the burden of interacting with multiple 
platforms from an application or a service, while platforms increase 
the portfolio of offered resources. For example, if Platform 2 offers to 
barter data produced by its static temperature sensors within a fed- 
eration formed by platforms 1 and 2, this means that Platform 1 can 
use and offer temperature readings produced by those sensors as If 
Platform 1 was managing the devices. 

Platform 1 offers in turn its temperature sensors located in an- 
other location to Platform 2. Therefore, an application or service can 
use the sensors from a single platform. Note that oneM2M has also 
identified such interaction between two platforms and tags the inter- 
face for platform interworking Mcc' (between two services providers). 


3.1.2. Semantic Interoperability 


Semantics, as seen in linguistics and philosophy, refers to the study of 
meaning, which means the relation of signifiers like words, symbols or 
signs and their denotation [12]. In computer science, the meaning of se- 
mantics is the same, but here the relations of signifiers and their deno- 
tation need to be understandable and process able by machines. 
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The most common way to achieve this is by using an ontology 
which is ‘an explicit specification of a [shared] conceptualization’ [6] and 
can be imaged like a formally defined information model. This is in line 
with the idea of the Semantic Web [13] introduced by Tim Berners-Lee in 
2001, proposing the evolution of the Internet from a web of documents to 
a web of machine-readable and -understandable data. The corner stone 
technologies of the Semantic Web are the Resource Description Format! 
(RDF), a lightweight (meta data) data model for describing ontologies, 
and SPARQL Protocol and RDF Query Language? (SPARQL), which both 
are standardized by the World Wide Web Consortium (W3C). 

To enable building new innovative applications which, make use 
of data from multiple loT systems, spanning existing “loT silos” these 
systems must not only be able to exchange raw data but also have a 
common understanding of its meaning. Unfortunately, even if today's loT 
systems are willing to expose their data and resources to others, their 
semantically incompatible information models, offering different de- 
scriptions or even understandings of resources and operational proce- 
dures become an issue. Therefore, semantic interoperability is defined 
as “the ability of computer systems to exchange data with unambiguous, 
shared meaning” [14] is the key to “data exchange and service creation 
across large vertical applications’, which is the next step of evolution of 
the loT [15]. 

The challenge in achieving semantic interoperability is to find a way 
to provide this unambiguous, shared meaning of things, i.e. bridging the 
semantic gap between two (or more) platforms. Figure 3.4. shows possi- 
ble approaches to semantic interoperability and their classification into 
three types. The shown approaches are an extension to the ones present- 
ed in [16] and form a solution space where each approach to semantic 
interoperability can be located. The solution space in the original paper 
ranges from the Core Information Model approach where all communi- 
cating platforms agree on one shared model to the Mapping between 


16, https://www.w3.org/RDF/ 
2. https://www.w3.org/TR/sparql11-overview/ 
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Platform-Specific Information Models approach where each platform is 
free to use whatever information model they like and interoperability 
is only achieved through mapping between them. We define two more 
approaches extending this range called Arbitrary Information Model (+ 
Domain-Specific Models) which do not solve the problem of semantic in- 
teroperability їп general but already provide the mechanisms needed 
to address semantic interoperability and therefore allow solving it on a 
different level. 

We also provide a classification of these approaches according to 
three types of (semantic) interoperability: by chance, by standardization 
and by mapping. Semantic interoperability by chance means, that each 
platform is free to use whatever model they like but is only interoperable 
to any other platform that, by chance, uses the same model. Semantic 
Interoperability by standardization refers to the fact that there is some 
kind of agreement or standardization regarding at least parts of the 
used model and (semantic) interoperability by mapping refers to the fact 
that mapping logic is used to translate between different models. 


Arbitrary Core Core Mapping between 
Information Information Information Platform-Specific 
Models Model Model with Extensions Information Models 
Soie Soc Oy 
O O O O O O O 
Arbitrary Multiple Multiple Pre-Mapped 
Information Models Pre-Mapped Core Best Practice 
+ Domain-Specific Models Information Models Information Models 
Interoperability | | 
=| bychance 
=| by standarization 
=] by mapping 


Figure 3.4. Possible approaches to semantic interoperability and their classification 
(based on [16]). 


loT-EPI Projects approaches 
addressing loT platforms 
interoperability 


loT-EPI Platforms - Architectural mapping 


The loT platforms adoption is driven by factors such as economics 
that add cloud services and the development of partner ecosystems. 
In this context, device manufacturers provide built in solutions and 
models with the lol SDKs to provide ease of use that allows the use 
of multiple portals and applications to get the loT platforms and de- 
vices fully configured. The relationship with the service providers is 
increasingly important with the integration within the loT suite and the 
various offerings from service providers. 

The development of standardisation is accelerating in the area of 
device discovery to support ability for heterogeneous devices to com- 
municate and interoperate. Standards are key to enabling interopera- 
bility, driving down costs and stimulating growth. However, standards 
processes are complex, take a long time to evolve and be adopted, 
and will still take some time to have mature, stable standards domi- 
nating, so suppliers and buyers are having to over-invest in multiple 
standards. 

In this complex environment, the loT-EPI projects are developing in- 
teroperability solutions that are addressing different layers in the loT ar- 
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chitecture and offer mechanisms for providing interoperability between 
different loT platforms addressing various use cases and applications. 

In the following paragraphs, we briefly discuss the mapping of 
the loT architecture layers to the activities and solutions provided by 
the loT-EPI projects. 

AGILE builds a modular hardware and software gateway for 
the loT focusing on the physical, network communication, process- 
ing, storage and application layers. The AGILE software modules are 
addressing functions such as device management, communication 
networks like area and sensor networks and solution for distributed 
storage. The project considers all the modules needed to provide a 
robust security management solution. 

bloTope provides an architecture and recommendations for the 
use of open standards and use case implementations that enable stake- 
holders to easily create new loT systems and services and to rapidly 
harness available information using advanced Systems-of-Systems 
(SoS) capabilities for Connected Smart Objects. bloTope also develops 
and provides standardised open APIs to enable interoperability. The 
project addresses all eight layers of the loT architecture and validates 
the interoperability solutions in a cross-domain environment. 

BIG loT develops a generic, unified Web API for loT platforms im- 
plemented. As part of the project, 8 partner loT platforms are being 
integrated with the ecosystem plus several additional platforms are 
joining via the community building process. The project focuses on 
the upper layers of the loT architecture by addressing the security 
management, APIs, service integration, external system Services, ap- 
plications, and the business enterprise. 

INTER-loT project addresses an open cross-layer framework, an 
associated methodology and tools to enable voluntary interoperability 
among heterogeneous loT platforms by focusing on six layers of the 
loT architecture with modules covering the QoS and device manage- 
ment, service integration, external system services, storage and virtu- 
alisation. The project addresses all network communication layer and 
the full security management suite. 
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symbloTe is providing an abstraction layer for a unified view on 
various loT platforms and sensing/actuating resources. Applications 
can use symbloTe Core Services implementing a semantic loT engine 
to find adequate resources offered by symbloTe-enabled platforms 
and subsequently access platform's virtual resources directly for data 
acquisition and actuation. The project focuses on seven layers of the 
loT architecture from physical to application layer and proposes a full 
security management suite. 

TagltSmart! offers a set of tools and enabling technologies that 
can be integrated into different loT platforms using provided APIs to 
enable users across the value chain to fully exploit the power of con- 
dition-dependent functional codes to connect mass-market products 
with the digital world across multiple application sectors. 

VICINITY focuses on a platform and ecosystem that provides “in- 
teroperability as a service” for infrastructures in the loT and addresses 
the five-upper layer of the loT architecture. The work considers the ser- 
vice integration, business logic, virtualisation, storage, APIs, tools, ex- 
ternal system services, applications, data analytics and cloud services. 


AGILE 


The AGILE project aims to address technical and syntactic interopera- 
bility at hardware and software levels. On the hardware front the project 
designs hardware components extending the current state-of-the-art 
of available loT gateway platforms with а twofold objective: to develop 
a so called “Maker's Gateway” by extending the capabilities of the most 
adopted and low-cost Raspberry Pi platform; and to develop a modu- 
lar hardware gateway design for industrial purposes. For the Maker's 
Gateway, the project contributes a shield following the Raspberry HAT 
specification? to the Open Hardware community, extending the capabil- 
ities of the platform by two additional sockets for radio modules, with 


3: The Rapberry Pi B+ HAT (Hardware Attached in Top) specification is an extension hardware 
module specification for newer Raspberry Pi models, which has also been adapted by 
several other gateway class HW platform manufacturers. 
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several sensors including a GPS, and with further wired sensor con- 
nectivity options. The project also provides code that helps developers 
visualise and eventually use the features of these in a web-based visual 
application development environment called Node-Red. The ease of use 
for these tools enables people with no software / hardware competenc- 
es to assemble their required solutions in a fast prototyping environ- 
ment used also for testing purposes and before mass production. 

On the software front the objectives of the AGILE project 
are to release open source code through the Eclipse Foundation 
to the community of loT software developers / makers, helping 
them to easily configure their devices or gateways according to 
the platform environment these will be part of. The code is de- 
signed with gateway platform interoperability in mind, minimizing 
dependencies and thus supporting not just the two gateways hard- 
ware platform variants developed inside the project but also other 
platforms available on the market. To this end, Docker container- 
ization (https://www.docker.com/) is used to separate software 
components from each other and from the underlying HW/OS. In 
fact, Docker is the leading containerisation technology for software 
containers, packages that contain software binary executables, 
runtimes and all related dependencies. 

To further facilitate HW support, the project also contributes to 
the development of the Linux Yocto-based ResinOS operating sys- 
tem, specifically tuned for docker-based multi-container deployments 
adaptable to a large number of loT gateway platforms. 

Interoperability of platforms is therefore more easily fostered 
with the creation of an ecosystem of loT applications that can be 
shared between users and developers leveraging existing initiatives 
like the Docker container ecosystem. Users are able to discover, in- 
stall/manage and share components that have been developed for 
interoperability purposes in a secure way through the Docker app 
marketplace. 

Figure 4.1 gives a more detailed view of what the AGILE Archi- 
tecture looks like and which are the various modules that, run as ex- 
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Figure 4.1. AGILE Detailed Architecture 


ecutable images in a container platform, enable it to address interop- 
erability. Worth highlighting for this purpose the loT Device and HW 
module Discovery and loT Device Communication (hardware interop- 
erability and the Device Management UI and loT Data Management 
UI (software interoperability) that encompass all aspects of syntactic 
interoperability. 

The top part of the picture shows how AGILE achieves horizontal 
interoperability of existing loT platforms by allowing users to utilise 
external platforms for data management (e.g., Dropbox and Google- 
Drive), APIs for loT devices (like wearable device APIs, home auto- 
mation APIs, etc.) and application scalable deployment (e.g., support 
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for CloudFoundry PaaS and integration of FIWARE enablers, Micro- 
soft Azure, etc.). AGILE addresses these challenges at the software 
level by providing loT platform specific modules for its Node-Red 
based visual application composition environment. With the catego- 
rization of Figure 3.2, this approach is similar to the "Cross Platform 
Access” pattern, with the notable difference that AGILE provides 
support in form of Node-Red modules, of which the application that 
uses features of both AGILE and several other cloud platforms can 
be composed. 

The project does not address any approach to semantic in- 
teroperability. 


BIG loT 


The goal of the BIG loT project is to remove technological market entry 
barriers of service and application providers of the Internet of Things 
by exploiting the capabilities of smart object platforms through estab- 
lishing syntactic and semantic interoperability via an open BIG loT АР! 
and BIG loT Marketplace to enable cross-standard, cross-platform, 
and cross-domain loT services and applications. Thereby, the project 
is defining a comprehensive architecture [17] for loT ecosystems in- 
cluding a solid security design [18] and service composition approach 
[19], while at the same time providing business models [20] that sus- 
tain the ecosystem. 


4.3.1 The BIG loT Architecture 


This subsection is based on the material published in [10] and [17]. 
Below, the architectural approach and related interoperability aspects 
of the BIG loT project are outlined. Figure 4.2 presents an overview of 
the BIG loT architecture for loT ecosystems. The architecture has been 
specifically designed to support all of the above-described patterns 
of interoperability (Section 4.1.1). The architecture is centred around 
a common set of interfaces, referred to as the BIG loT API, that are 


31 lo T-EPI PROJECTS APPROACHES ADDRESSING IOT PLATFORMS INTEROPERABILITY 


BIG loT-conform Service 


P2 Consumer 


BIG loT-conform Application 


Q 


М1 Authentication 


Al Access 1 Authorization 


О 
M2 Registry BIG IoT 
P1 Provider — Marketplace 


1 BIG lor O 


P2 Consumer [2 Consume Lib M3 Discovery 


P2 Consumer 


BIG loT Application 


Ọ Al Access Q 


A access 


P1 provider 


BIG loT enabled Platform 


Mode 1: 
Programmatic Integration 


Mé Accounting 
E 
= 
= = 
а 3 
E & 
Е E 
a | 
П 
1 Web Portal BIG loT Marketplace | 
| 1 
| 1 
| 1 
| ч 
| Authentication "m 1 
1 
M1 authetication | Administration d 
M2 registration 1 1 
M3 discovery Offering + 1 
ы i 
p 1 Query Management BIG cT BIG loT | 
П eXchange 
i Charging Marketplace y 1 
API | 
BIG loT Lib | 1 
(Consumer) | Developer Support 1 
A 1 
BIG loT Service П Charging 4 
p | І 
BIG loT Lib | ] 
(Consumer) : e 1 
——————————— ы. ш 
BIG loT API 
Al access 
e 
I vit 
SERRE BIG loT Lib (Provider) 
(Provider) 


Proxy 
Service Logic 


BIG loT enabled Platform 
BIG loT enabled Platform 


BIG IoT Lib (Proxy) 


P3 provider 


XX integration XX integration 


BIG loT enabled Platform 


Mode 2: Mode 1: Mode 1: 
Getaway-Service Integration Management-Service Integration Proxy-Service Integration 


Figure 4.2. BIG loT Architecture Overview A [10] and B [17]. 
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supported both by offering providers and consumers, as well as the 
marketplace, where resources are traded. These interfaces include 
the following basic interactions: 


e M1: Authentication & authorization of offering providers and 
consumers 

* M2: Registration of offerings (through offering providers) 

• M3: Querying of offerings (through offering consumers) 

e МА: Accounting of offering access 

e Al: Access to offerings requested by offering consumers 


These interfaces are the basis for enabling interoperability and 
realizing the patterns | – V (Section 4.1.1). Thereby, key challenges for 
realizing patterns Il, III, and V are e.g.: 


e The offering providers and consumers are from different ap- 
plication domains (11); 

e The loT offerings are hosted on different loT platforms, e.g. lo- 
cated in different regions (111); 

e The loT offerings are on different provider systems, e.g. an loT 
platform or a service (V). 


Important in this figure is also the concepts of the BIG loT Con- 
sumer and Provider Libs. For example, the Provider Lib implements 
the Register interface (M2) for uploading a description of an offer- 
ing to the marketplace and offers the Access interface (A1) to provide 
the information to a consumer. The benefit of these libraries is that 
developers of platforms, services and applications are supported in 
advertising their offerings on the marketplace or use the marketplace 
to discover and access them. They only have to implement once the 
Provider (P1) or Consumer (P2) interface and can easily update the 
libraries in order to further comply in case of changes in the details of 
the underlying message formats and interactions. For the registration 
process via the Register interface (M2) a semantic description is used 
that is called an Offering Description and relies on the Resource De- 
scription Framework (RDF). 
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4.3.2. loT platforms interoperability approach 


A central goal of the BIG loT architecture is to facilitate the integration 
of loT platforms through the BIG loT ecosystem. Both infrastructure 
as well as device-level platforms are targeted. From an architectural 
perspective, specifically considering the implementation of the BIG loT 
API and integration with marketplaces, we have identified the follow- 
ing types of loT platforms: 


Type 1: Server Infrastructure or Cloud based loT Platform as- 
sumed to be “always online” and anytime accessible by appli- 
cations or services via the Internet. 

Type 2: Device-level loT Platform, hosted on devices that are 
unconstrained‘ with respect to communication, compute and 
memory resources assumed to be “always online” whereby 
connectivity and communication resources is assumed to be 
charged on a “flat-rate” plan. 

Type 3: Device-level loT Platform, hosted on devices that are 
unconstrained with respect to communication, compute and 
memory resources, but are “not always online”. 

Type 4: Device-level loT Platform, hosted on devices that are 
unconstrained-with respect to communication, compute and 
memory resources, but are connected to the Internet via a 
"pay-per-use" plan, Type 4 devices are often also of Type 3. 
Type 5: Device-level loT Platform, hosted on devices that are 
constrained? with respect to communication, compute and/or 
memory resources. 


4. Unconstrained in this context means that the device will be able implement/use the BIG loT 
API, which will be based on typical Web/Internet technologies (e.g. HTTP WebSockets). An 
example of an unconstrained device is a Raspberry Pi. Also, other devices that are able to 
run Linux and support typical Web/Internet technologies are considered unconstrained in 
this context. A micro-controller based Sensor is not considered unconstrained. 


5. Constrained in this context means with respect to the implementation of the BIG loT API, 
which will be based on typical Web/Internet technologies (e.g. HTTP, WebSockets). An ex- 
ample of constrained devices are low-cost sensors, using a micro-controller. A Raspberry 
Pi is not considered a constrained device. 
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In the BIG loT Project, overall 8 platforms are integrated by the 
partners. First, 6 cloud- or infrastructure-level platforms are part of 
the ecosystem: Bosch's Smart City platform, based on the Bosch loT 
Suite“ (Type 1; Mode 1, Mode 2, Mode 4), CSI's Smart Data” platform 
(Type 1; Mode 3), OpenloT? ( Type 1; Mode 1, Mode 2), VMZ's TIC? plat- 
form (Type 1; Mode 1, Mode 2), Siemens APM platform (Type 1; Mode 
2), and WorldSensing'? (Type 1; Mode 1, Mode 2). Further, there are 
2 device-level platforms: Bosch's BEZIRK"' platform (Type 2, Type 3, 
Type 4; Mode 1, Mode 4) and Econais' Wubby?? platform (Type 2, Type 
3, Type 4, Type 5; Mode 4). 

Those now BIG loT-enabled platforms are integrated via the BIG 
loT API and BIG loT Marketplace and currently being rolled out and 
tested in 3 European Pilot sites and applied in loT scenarios for Smart 
Cities: Barcelona (BCN), Berlin/Wolfsburg (МС), and the region of Pied- 
mont (Pied). Our Use Cases are divided in 9 clusters: Smart Parking 
(NG, BCN, Pied), Smart Traffic Management (BCN, Pied), Public Trans- 
port Optimization (NG, BCN), Healthy Bike Navigation (BCN, Pied), Smart 
Bike Sharing (NG, BCN, Pied), Incentive-based Green route Planning 
(BCN, Pied), Multi-Modal Route Optimizer (NG), Smart Charging (NG, 
BCN), Device-to-Device Communication (BCN), Smart Living (NG). In 
NG we use Bosch's Smart City platform, VMZ's TIC platform, Siemens 
APM Platform; in BCN are used OpenloT, WorldSensing, Bosch's BE- 
ZIRK; Pied integrates CSI's Smart Data and Econais' Wubby platform. 


4.3.3. Interoperability aspects 


Solving interoperability issues related to these patterns requires the 
use of common information models, e.g., offered through Semantic 


ps://www.bosch-si.com/products/bosch-iot-suite/platform-as-service/paas.html 
p://www.smartdatanet.it 

p://www.openiot.eu/ 

ps://viz.berlin.de/en/home 

p://www.worldsensing.com 
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Web technologies. Those common information models need to allow 
the description of offerings, so that their consumers (e.g., services 
or applications) can work with them, even if they are from differ- 
ent domains or systems. The BIG loT Core Model defines the core 
vocabulary required to create an Offering Description. The Offering 
Description relies on the work done within the W3C Web of Things 
(WoT) group, in particular, the Thing Description (TD) format [21] and 
going to be mapped also to W3C SSN/SOSA. The semantics are fur- 
ther enriched by domain independent and domain dependent mod- 
els. A domain dependent model is used to semantically annotate the 
metadata, offering category and input/output data of an Offering De- 
scription. The BIG lol semantic Application Domain Model is created 
using the BIG loT semantic Core Model, domain independent and/ 
or domain models. This model establishes the relationship between 
the core model and domain model. Along with offering categoriza- 
tion and data modeling, the Domain Model also defines the vocabu- 
lary to semantically annotate the domain dependent features of an 
offering. For example, the class “mobility:ParkingSpace” can be used 
to annotate a parking space and its features such as parking space 
id, or parking space location. 

For the semantic annotation of offering descriptions, e.g., defin- 
ing the semantics of inputs, outputs and offering category, a well-de- 
fined vocabulary of domain terms is needed. This vocabulary should 
be widely shared and agreed upon so that all consumers and pro- 
viders of loT platforms can rely on it. Further, it should evolve in an 
open community process to allow active engagement by ecosystem 
stakeholders. We have selected schema.org as a basis for our domain 
model, as it provides a vendor-neutral, community-developed vocab- 
ulary for structured data. 

The central pillar of the ecosystem is the Marketplace. Here, a 
Provider (e.g., an loT platform) registers its resources by uploading an 
offering description (Section 3.2). To facilitate a provider in conform- 
ing with the BIG loT API for offering its resources in the ecosystem, 
the Provider Library (Lib) can be utilized. It can be used to establish 
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a gateway to the actual resources and implements the BIG loT API 
and the various interactions and workflows (Section 3.4). The library 
authenticates the provider with the Marketplace and registers its of- 
ferings. It also offers a Web API to grant access to the resources. 

Beyond these mechanisms for providing access to loT platforms, 
the Marketplace enriches the ecosystem with the possibility of mon- 
etizing the consumption of resources. Therefore, both sides, the con- 
sumer and provider, report accounting data (e.g. number of resource 
records obtained/provided) back to the Marketplace. This is the basis 
for charging and billing, and the foundation for business opportunities 
around the ecosystem. 

The above described loT ecosystem is platform-scale indepen- 
dent. l.e., loT platforms can operate either on cloud-level (e.g., server, 
data centre), on fog-level (e.g., gateway, cellular communication base 
station), or on device-level (e.g., Raspberry Pl, smartphone). In the last 
case, the loT platform can represent an loT ‘thing’. The BIG loT API can 
be used independent of this scale of the platform. 


4.3.4. Uniqueness and specific features of the approach 


The BIG loT approach comprises the following objectives: First, it 
openly defines the so-called BIG loT API, a generic, Web-based appli- 
cation programming interface (API) for the adoption by smart object 
platforms. 

Second, at the core of BIG loT ecosystem stands an open market- 
place. Once the BIG loT API provides the building blocks for a syntacti- 
cally and semantically interoperable loT and inter-platform connectiv- 
ity and exchange is enabled, the marketplace lays the foundation for 
an ecosystem of platforms and services offerings. The marketplace 
enables the advertisement, quality control, and monetization of ap- 
plications and services developed on top of the BIG loT API. A mar- 
ketplace can be setup for specific domains, e.g., by stakeholders for 
the industry or energy domain, or by Smart Cities for the mobility or 
building domain. 
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Third, BIG loT supports the development of applications and ser- 
vices by providing a dedicated software infrastructure. In addition, it 
provides functionality to discover and orchestrate services. This func- 
tionality is based on semantic service descriptions and an automated 
service chaining will be enabled through semantic reasoners. These 
functionalities facilitate the reusing of existing services. 

Fourth, BIG loT project engages with current standardization ini- 
tiatives to receive input and further on, we will contribute to those 
standardization activities with the results elaborated in the project. 

Finally, the core technologies related to BIG loT API and Market- 
place will be available as open source under Eclipse. The BIG loT pro- 
posal has been approved and the Eclipse Bridge.loT project has been 
created (https://projects.eclipse.org/proposals/eclipse-bridge.iot) 

Used approach to semantic interoperability: Arbitrary Informa- 
tion Model and Domain-Specific Models 


bloTope 


A primary goal of bloTope is to enable companies to easily create new 
loT systems and rapidly harness available information using advanced 
Systems-of-Systems (SoS) capabilities for Connected Smart Objects. 
This SoS approach signifies that all five patterns of interoperability 
in Figure 3.2 are implemented through open standards that can be 
combined and used together in different ways. The SoS approach tak- 
en by bloTope differs from most other proposed architectures for loT 
systems in the sense that there is no layered architecture regarding 
the physical size or computational capabilities of the communicating 
systems. With this SoS approach, patterns 1-11 in Figure 3.2 are basic 
requirements that are implemented by default. Any system that im- 
plements the necessary loT standards can communicate directly with 
any other system that implements and understands the same stan- 
dards, as illustrated in Figure 4.3. This capability implements pattern 
IV) “Platform-Scale Independence” in Figure 3.2. 
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Systems that do not natively support the necessary loT stan- 
dards can join by what we call Wrappers in bloTope, i.e. software com- 
ponents that expose the services that should be published to the loT 
level using the appropriate standards (this corresponds to pattern V) 
"Higher-level Service Facades" in Figure 3.2). This also signifies ensur- 
ing that data and services that are not public remain non-accessible 
to unauthorized parties. 

In bloTope, “ТоТ standard” signifies a limited set of appropri- 
ate standards around the "waist" of the standards landscape as 
illustrated in Figure 4.4. If the loT is expected to become a sim- 
ilar success story as the World Wide Web (WWW), it will need a 
similar foundation with a set of simple, well-defined, generic and 
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Figure 4.3. bloTope Systems of Systems type cross-connected (non-layered) connec- 
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Figure 4.4. Illustration of bloTope standards landscape. 


powerful standards. The WWW started with HTTP and HTML as the 
initial core standards. Over time supplementary functionality has 
been introduced by other standards that augment the capabilities 
of WWW applications but the fundamental building blocks and prin- 
ciples are still the same. 

The core loT standards used in bloTope are shown in bold. The 
other standards are used depending on the domain and requirements 
of different applications. When other standards (or proprietary proto- 
cols and formats) than the core loT standards are used, bloTope uses 
a Wrapper (i.e., a Service Facade) for making them compliant with the 
core loT standards. 

bloTope takes full advantage of messaging standards developed 
and officially published by The Open Group, notably the Open Mes- 
saging Interface (0-MI) and Open Data Format (O-DF) standards"? 


13. Formerly called QLM-MI and QLM-DF for historical reasons. 
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[22] [23]. Those standards emerged out of past EU FP6-FP7 proj- 
ects, where real-life industrial applications required the collection 
and management of product instance-level information for many 
domains involving heavy and personal vehicles, household equip- 
ment, etc. Based on the needs of those real-life applications, and 
as no existing standards could be identified that would fulfil those 
requirements without extensive modification or extensions, the 
partner consortia started the specification of new loT interopera- 
bility standards. O-MI mainly provides Technical Interoperability in 
the stack of Figure 2.1 with the necessary functionality needed for 
implementing generic loT systems that is not provided by protocols 
such HTTP. O-MI can be used for implementing RESTful loT informa- 
tion systems, also using other underlying protocols than HTTP as 
illustrated in Figure 4.5. 

O-DF provides a generic content description model for Objects in 
the loT that can be extended with more specific vocabularies (e.g., us- 
ing domain-specific ontology vocabularies). O-DF currently uses XML 
as the underlying syntax but it provides a minimal, generic set of se- 
mantics for annotating loT (and other) data. O-DF could be considered 
to bridge Level 2 (syntactic interoperability) and Level 3 (semantic in- 
teroperability) in Figure 4.5 because it provides a capability to refer- 
ence external taxonomies, ontologies and vocabularies in a platform-, 
domain- and scale-agnostic way. 

Figure 4.5 illustrates a bloTope ecosystem, where the different 
loT standard compliant systems (through Wrappers or not) are aware 
of each other's existence and the different data and services that they 
provide to each other"’. When a new system needs to “join” a bloTope 
compliant ecosystem, e.g. a car that arrives into a new city and needs 
to discover available services, bloTope will provide discovery mecha- 
nisms for discovering relevant O-MI nodes. Certain nodes will imple- 


Tá: bloTope assumes that different nodes can publish different data and services depending 
on the requesting node's identity, role, current context and other parameters. bloTope also 
develops software components for the management of such access rights. 
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Figure 4.5. bloTope ecosystem illustration. 


ment the bloTope loTBnB API, which is a marketplace for loT compli- 
ant services. 

Figure 4.6 illustrates how different platforms, systems and services 
can publish the desired data and services using loT standards. The Open 
Data Format (O-DF) provides means for annotating “any” loT data or ser- 
vice using existing or new vocabularies, such as schema.org, SSN, GML, 
etc., as shown in Figure 4.4. lt is even possible to use several different 
vocabularies within one O-DF structure (including proprietary ones) by 
linked data principles. 
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Figure 4.6. bloTope architecture illustration. 
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The bloTope architecture is heavily influenced by a Micro-Services 
Architecture (MSA) thinking, where different “small” standards can be 
used jointly in the best way depending on application requirements. MSA 
is a generic way of implementing pattern V) “Higher-level Service Fa- 
cades” in Figure 3.2. Support for MSA is a fundamental design principle 
of O-MI and O-DF in the sense that services of “any” size can be published 
and consumed, no matter if it is a simple request for a current sensor 
value or a request for available parking places in proximity of a car’s cur- 
rent location. 

Such an MSA approach provides several advantages regarding 
system flexibility and lean software principles because new loT stan- 
dards-compliant services can be composed from smaller, existing 
services. It also provides a risk management advantages in the cur- 
rent competitive loT standardization landscape because different stan- 
dard-compliant software components and wrappers can be adapted to 
support new or “winning” standards without impacting the whole system 
architecture. 

Whilst bloTope should be understood as a highly flexible and dy- 
namic ecosystem capable of seamlessly integrating arbitrary proprietary 
loT platforms, it nevertheless builds upon a number of several core com- 
ponents presented in the top layer of Figure 4.6, which provide essential 
functionality. The basic viewpoint coordinates of from the architectural 
framework is presented in Figure 4.7. This figure adopts the conventions 
established, for example, by NIST'5 or loT-A'® with regards to the mean- 
ings of the cardinal directions North-South-East-West and set interaction 
patterns to human (north / west) and machines (south / east). 

Nevertheless, the presented Services (XaaS) can be seen basical- 
ly as chained micro services or functional blocks. Composed function- 
al blocks result in a specific services, which as well can be part of an 
aggregation of several services. Figure 4.8 introduces a functional view 
onto those micro services, labelled as functional blocks. Basis for all 


15. https://www.nist.gov/sites/default/files/documents/itl/antd/Jeff Voas.pdf 
16. http://www.meet-iot.eu/deliverables-IOTA/D1_3.pdf 
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Figure 4.7. bloTope concept illustration. 


functional blocks inside the ecosystem is the compliance to O-MI and 
O-DF. This compliance brings automatically the fundamental services for 
“publication” and “consumption” and their inherited sub-functions. For 
the interconnection of various services appearing in the ecosystem, the 
“marketplace / service catalogue” sets a cornerstone to interact as an 
intermediator between services. One possible instance of this services is 
represented by the loTBnB" implementation. This specific implementa- 
tion is as well supported by the Security 8. Privacy service that handles 
unauthorized actions. Inside of the ecosystem are other services (Visual- 
ization, Context Provisioning, Service Composition and RDF Integration 8 
Semantics) that help to realize the stated core components / services on 
the top layer of Figure 4.6. 


17... http://iotbnb.jeremy-robert.fr/#/home 
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Figure 4.8. bloTope reference architecture. 


Used approach to semantic interoperability: Arbitrary Information 
Model + Domain-Specific Models 


INTER-loT 


4.5.1. Uniqueness and special features of the approach 


INTER-loT offers a layer-oriented solution for enabling seamless loT 
platforms’ interoperability. With this solution, different platforms can be 
interconnected and transparently interoperate among them at any spe- 
cific layer or level (Device, Network, Middleware, Application and Data 
and Semantics). INTER-loT is the first approach in providing universal 


ADVANCING loT PLATFORMS INTEROPERABILITY 46 


semantic translation among platforms. It also provides a methodology 
(INTER-METH) for guiding and easing the implementation. INTER-loT 
open framework (INTER-FW) offers a set of tools for interoperability at 
each specific layer which can be accessed through an API. Furthermore, 
INTER-loT offers a virtualized version of each layer solution to facilitate a 
quick implementation with Docker. 

INTER-loT solution can be applied to any application domain and 
across domains in which there is a need for interconnection and/or in- 
teroperability. INTER-loT will facilitate the formation of interoperable loT 
ecosystems, make the design of loT devices, smart objects or services 
easier to companies and developers, and support launching them to the 
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Figure 4.9. INTER-loT layered architecture 
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market quickly to a broader client base. In the long term, the ability for 
applications to connect to and interact with heterogeneous smart objects 
will become a huge enabler for new products and services. 


4.5.2. INTER-loT Architecture 


INTER-loT presents a novel layer-oriented solution for interoperability, to 
provide interoperability at any layer and across layers among different 
loT systems and platforms. Contrary to a more general global approach, 
the INTER-loT layered approach has a higher potential in order to pro- 
vide interoperability. It facilitates a tight bidirectional integration, higher 
performance, complete modularity, high adaptability and flexibility, and 
presents increased reliability. 

This layer-oriented solution is achieved through INTER-LAYER, sev- 
eral interoperability solutions dedicated to specific layers. Each interoper- 
ability infrastructure layer has a strong coupling with adjacent layers and 
provides an interface. Interfaces will be controlled by a meta-level frame- 
work to provide global interoperability. Every interoperability mechanism 
can be accessed through an API. The interoperability infrastructure layers 
can communicate and interoperate through the interfaces. This cross-lay- 
ering allows to achieve a deeper and more complete integration. 


4.5.3. Layers and interoperability aspects 


Device layer (D2D): At the device level, D2D solution will allow the seam- 
less inclusion of novel loT devices and their interoperation with already 
existing ones. D2D solution is a modular gateway that supports a vast 
range of protocols as well as raw forwarding. It is composed on a physi- 
cal part that only handles network access and communication protocols, 
and a virtual part that handles all other gateway operations and services 
(gw virtualization). When connection is lost, the virtual part remains func- 
tional and is capable to answer the АР! and Middleware requests. The 
gateway follows a modular approach to allow the addition of optional ser- 
vice blocks to adapt to the specific case, allowing a fast growth of smart 
objects ecosystems. 
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Network layer (N2N): N2N solution enables seamless Network-to-Net- 
work interoperability, allowing transparent smart object mobility, and in- 
formation routing support. It will also allow offloading and roaming, what 
implies the interconnection of gateways and platforms through the net- 
work. Interoperability is achieved through the creation of a virtual network, 
using SDN and NFV paradigms, with the support of the N2N API. The N2N 
solution will allow the design and implementation of fully interconnected 
ecosystems, and solve the smart object mobility problem. 

Middleware layer (MW2MW): At the middleware level INTER-loT 
solution will enable seamless resource discovery and management 
system for the loT devices in heterogeneous loT platforms. Interopera- 
bility at the middleware layer is achieved through the establishment of 
an abstraction layer and the attachment of loT platforms to it. Different 
modules included at this level provide services to manage the virtual 
representation of the objects, creating the abstraction layer to access all 
their features and information. Those services are accessible through a 
general API. Interoperability at this layer will allow a global exploitation of 
smart objects in large scale multi-platform loT systems. 

Application and Services layer (AS2AS): INTER-loT will enable the 
use of heterogeneous services among different loT platforms. Our ap- 
proach will allow the discovery, catalogue, use and even composition of 
services from different platforms. AS2AS will also provide an API as an 
integration toolbox to facilitate the development of new applications that 
integrate existing heterogeneous loT services. 

Semantics and Data layer (DS2DS): INTER-loT guarantees a com- 
mon interpretation of data and information among different loT platforms 
and heterogeneous data sources that typically employ different data for- 
mats and ontologies, and are unable to directly share information among 
them. INTER-loT DS2DS approach is the first solution that provides uni- 
versal semantic and syntactic interoperability among heterogeneous loT 
platforms. It is based on a novel approach, a semantic translation of loT 
platforms’ ontologies to/from a common Central Ontology that INTER-loT 
employs, instead of direct platform-to-platform translations. This tech- 
nique reduces dramatically the number of potential combinations of 
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semantic translations required for universal semantic interoperability. 
INTER-loT semantic interoperability tools work with any vocabulary, or 
ontology. INTER-loT own modular Central Ontology, called GOIoTP for all 
loT platforms, devices and services, is available at http://docs.inter-iot. 
eu/ontology. Also, syntactic translators allow interoperability between 
different data formats, such as JSON, XML, and others. Although the pilot 
deployments of INTER-loT realize the Core Information Model with Ex- 
tensions approach to semantic interoperability, INTER-loT supports any 
solutions between its pilot approach and Core Information Model. 

Cross-Layer: Inter-loT also guarantees non-functional aspects that 
must be present across all layers: trust, security, privacy, and quality of 
service (QoS). As well, INTER-loT provides a virtualized version of the 
solution for each layer, to offer the possibility of a quick and easy deploy- 
ment. Security is guaranteed inside each individual layer, and the external 
API access is securitized through encrypted communication, authentica- 
tion and security tokens. INTER-loT accomplishes the new European Data 
Privacy Law, and in the specific case of e-Health, in which information is 
highly sensitive, the Medical Device Regulation law. 

Regarding the architectural interoperability patterns described in 
Section 3.1.1, INTER-loT supports all six patterns of interoperability: 


e Cross Platform Access, which is accomplished through AS2AS 
services or through MW2MW. 

e Cross Application Domain Access, as far as INTER-loT is do- 
main-agnostic and has universal semantic interoperability by 
means of the DS2DS solution. 

e Platform Independence, through AS2AS service composition and 
DS2DS semantic and syntactic translation. 

e Platform-Scale Independence, by means of INTER-loT AS2AS. 

e Higher-level Service Facades, through INTER-loT AS2AS services. 

e Platform-to-Platform interaction, INTER-loT main goal by design. 
It is achieved through 020 and/or MW2MW solutions. 


All the aforementioned patterns are architectural. INTER-loT 
has identified main patterns of interoperability from a different point 
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of view or analysis: from the semantic point of view, regarding se- 
mantic interoperability and from the middleware interoperability 
point of view (related with syntactic and functional interoperability). 
INTER-loT has its own macro and micropatterns that match with this 
approach. 

Finally, regarding the three main types of interoperability (func- 
tional, syntactic, semantic), INTER-loT enables all of them. Universal 
syntactic and semantic interoperability among any platforms with dif- 
ferent data formats and ontologies is possible through the INTER-loT 
DS2DS solution. Moreover, other INTER-loT layers (D2D & N2N) can pro- 
vide functional interoperability among smart elements, enabling con- 
nectivity to the network. 


symbloTe 


The main goal of symbloTe (symbiosis of smart objects across loT en- 
vironments) is to devise a flexible and secure interoperability middle- 
ware across loT platforms facilitating rapid development of loT appli- 
cations across platforms, platform collaborations as well as dynamic 
and adaptive smart spaces. This is accomplished by 1) a semantic 
loT search engine for connected (virtualized) smart objects (i.e., loT 
resources) registered by platform providers, 2) abstraction layer for 
unified and secure usage of those resources across platforms, 3) 
high-level, domain-specific APIs (“Enablers”) for rapid cross-plat- 
form application development, 4) loT platform federations, i.e., asso- 
ciations between two platforms facilitating their secure interaction, 
collaboration and bartering of resources, 5) dynamic and self-config- 
urable smart spaces offering interoperability for collocated devices 
and gateways, and 6) secure interworking protocol between the loT 
platforms, gateways and smart devices. This supports SMEs and new 
entrants in the loT market to build innovative loT services within short 
development life cycles. 
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Figure 4.10. The symbloTe high-level architecture 


4.6.1. The symbloTe Architecture 


The symbloTe architecture [24] is built around a layered loT stack con- 
necting various devices (sensors, actuators and loT gateways) within 
Smart Spaces with the Cloud. Smart Spaces share available local re- 
sources (connectivity, computing and storage), while platform services 
running in the Cloud enable loT Platform Federations and open the Inter- 
working API! to third parties with flexible access control. The architec- 
ture comprises four layered domains, as depicted in Figure 4.10. 


18. Interworking Interface is a symbloTe defined interface which opens up platform resources 
as RESTful loT Services in the Cloud Domain. 
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1) Application Domain enables platforms to register loT devices 
which they want to advertise and make accessible via the Interworking 
API, while symbloTe provides the means to search for loT devices across 
platforms by means of its Core Services. We also build domain-specific 
back-end services (Enablers) which utilize the infrastructure provided 
by the underlying platforms to offer value-added services, e.g., data 
analytics on top of sensor data acquired from different platforms. En- 
ablers ease the process of cross-platform and domain-specific appli- 
cation development (specifically for mobile and web loT applications). 

Cloud Domain provides a uniform and attribute-controlled ac- 
cess [25] to virtualized loT devices exposed by platforms to third 
parties through an open API (Interworking API). In addition, it builds 
services for loT Platform Federations enabling close platform collab- 
oration and resource bartering, in accordance with platform-specific 
business goals and defined Service Level Agreements (SLAs). 

Smart Space Domain offers services for discovery and interwork- 
ing of collocated loT devices and gateways in local spaces, while Smart 
Device Domain relates to the roaming capabilities of smart devices that 
maintain their identity while moving through different spaces. 


4.6.2. loT platforms interoperability approach 


symbloTe allows for flexible loT platforms interoperability mechanisms 
(direct platform-to-platform interactions within platform federations, 
platform-to-platform interactions within Smart Spaces) which is achieved 
by an incremental deployment of symbloTe functionality across the in- 
troduced architectural domains so that platform providers can choose 
an appropriate interoperability solution and integrate only selected fea- 
tures with their platforms. This in effect influences the level of platform 
interoperability and collaboration with other platforms within a symbl- 
oTe-enabled ecosystem. The currently conceived solution has a minimal 
impact on existing loT platforms as it requires mostly the development 
of a small interworking module. In addition symbloTe is adding security 
layer offers a distributed, and effective mechanism for controlled access 
to resources in a federation of heterogeneous loT platforms. 


53 lo T-EPI PROJECTS APPROACHES ADDRESSING IOT PLATFORMS INTEROPERABILITY 


ЕГ Level 1 
Application compliance 
Domain (L1) 
Cloud Level z 
Domain e d 
Level 3 
Smart Space compliance 
Domain (L3) 
А Level 4 
Smart Device Level 4: roaming devices compliance 
Domain (L4) 


Figure 4.11. symbloTe Compliance Levels 


4.6.3. Interoperability Aspects 


The symbloTe approach defines four interoperability levels, as depict- 
ed in Figure 4.11. We also refer to them as compliance levels, when 
considering them from the perspective of an loT platform wanting to 
become interoperable. In all four levels, interoperability is achieved by 
offering а unified and secure way to advertise, find and consume loT 
resources, but in each level, a different interoperability scenario is en- 
abled offering various degrees of details about the involved resources. 

Level 1 enables interactions between loT applications and virtual- 
ized loT resources (both sensors and actuators), i.e., applications can 
find and use resources across platforms through uniform interfaces. 
In addition, platforms can integrate symbloTe components for flexible 
attribute-based access control. Level 2 allows loT platforms to collab- 
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orate closely by forming federations. Federations can be considered as 
a closed and distributed version of the Core Services, i.e., the platforms 
can advertise and barter resources only to the members of the federa- 
tion. Level 3 enables dynamic smart spaces: adoption of new resources 
at the gateway level and direct interactions between symbloTe-enabled 
loT devices (e.g. mobile devices and Arduino boards) in collocated smart 
spaces, even if they are connected to various gateways and managed 
by different loT platforms. This enables resource migration between 
collocated and in proximity loT gateways to prevent vendor lock-in. 
Level 4 offers support for roaming of loT devices which maintain their 
unique identity while on the move, and can always be found via the Core 
Services, regardless of their current location. Level 1 can be directly 
mapped to semantic and syntactic interoperability, as defined in the IERC 
Whitepaper on Interoperability [26]. Levels 2, 3 and 4 relate to organi- 
zational interoperability. symbloTe proposes here an original approach 
with finer granularity of organizational interoperability by placing spe- 
cific interoperability concepts in either the Cloud or Smart Space. 


4.6.4. Uniqueness and specific features of the approach 


The first unique feature of symbloTe is its solution for semantic interop- 
erability that follows the Core Information Model with Extensions approach 
presented in Section 3.1.2. The Core Information Model (CIM) is the central 
information model used to describe resources registered to symbloTe 
and is shared between all platforms. It is designed to be as abstract and 
minimalistic as possible and at the same time as specific as needed to 
create a minimal mutual understanding. This way, the CIM enables limited 
out-of-the-box interoperability between all platforms. To actually register 
resources with symbloTe, platforms use Platform-Specific Information 
Models (PIMs) that are extensions of the CIM including platform-specific 
terms. As each PIM is an extension of the CIM, basic interoperability is en- 
sured, even between platforms using different PIMs. Such flexibility goes 
beyond the state of the art and is expected to lead to a high acceptance by 
platform owners, especially SMEs, as the process of adapting their plat- 
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form's information model to symbloTe is significantly simplified while it 
offers the means to use their existing information models. 

Furthermore, symbloTe develops a strategy to enable a higher-lev- 
el of interoperability between platforms using different PIMs. It is based 
on a translation between different PIMs based on declarative mappings 
using SPARQL query re-writing and data translation. This concept has 
the potential to create high impact on semantic interoperability for loT 
solutions since the process of information model standardization is fre- 
quently lengthy and cumbersome, while it also limits platform's flexibility. 

The second unique feature relates to the implemented semantic 
search engine for loT resources that is provided by the Core Services that 
let loT application developers find adequate loT resources for various 
cross-platform and cross-domain applications. The search engine uses 
and supports the listed symbloTe information models. 

The third uniqueness relates to direct platform-to-platform interac- 
tions within platform federations for closer collaboration between plat- 
forms. Here symbloTe goes a step further to provide novel functionalities 
for enriching platform interactions: resource bartering, trust and SLA 
management, as well as support for smart device roaming across fed- 
erated platforms. 

The fourth uniqueness relates to the security perspective. symbl- 
oTe implements a flexible, distributed, and effective mechanism for con- 
trolled access to resources, both sensors and actuators, in a federation 
of heterogeneous loT platforms. The conceived methodology grounds 
its roots in the powerful Attribute-Based Access Control mechanism. A 
specific access policy, defined as a combination of attributes (i.e., user's 
properties, roles, details) is assigned to each resource, while the access 
to that resource can be granted only to users in possession of a set of 
attributes matching the aforementioned policy. 

The above listed features allow symbloTe to support all six patterns 
of interoperability presented in Section 3.1.1. 

All six patterns of interoperability presented in Section 3.1.1 are 
supported by symbloTe and can be mapped to the above listed features. 
Pattern I, ll and Ill are supported through the provided Core services (e.g. 
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search for resources), the Interworking API, support for PIMs and se- 
mantic mapping. Pattern IV (Platform-Scale Independence) fits to the four 
interoperability/compliance levels of symbloTe; pattern V (Higher-Level 
Service Facade) matches the concept of Enablers and pattern VI (Plat- 
form-to-Platform Direct Interactions) the concept of federations as de- 
fined in symbloTe. 

symbloTe is implementing an Open Source middleware proto- 
type available at https://github.com/symbiote-h2020, following an ag- 
ile-like approach. Developers from all consortium partners join forces 
in the implementation of the software components using the micros- 
ervices architecture to fulfil the requirements of incremental feature 
deployment and scalability of the highly-distributed loT ecosystem. 
Regarding licensing, the consortium has selected a “copyleft” license 
for the Core Services (LGPL-3.0), so that updates, bug fixes and new 
features are always given back to the Open Source Community. For the 
middleware components residing at the platforms’ side the licensing is 
following the "non-copyleft" approach (the BSD 3-Clause is selected). 


TagltSmart 


A comprehensive view of TagltSmart architecture components is pre- 
sented in Figure 4.12. TagltSmart is designed as a set loosely coupled 
components which can be integrated in and across different envi- 
ronments (loT platforms). To this end, components providing specific 
TagltSmart functionality like smart tag encoding, decoding etc. come 
with their own APIs, while more generic loT functions are reused 
from the underlying loT platform used. This approach makes use of 
TagltSmart functionality rather straightforward in different settings 
and reduces the learning curve for developers. 

From the functional point of view, the User/Developer level 
provides the front end functionality enabling access to different 
TagltSmart components. Additionally, at this level, the TagltSmart 
SDK enables integration of the smart tag decoding functionality 
into third party (smartphone) applications. 
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Figure 4.12. TagltSmart Platform Functional Architecture 


At the Service level, we can find the following functional blocks: 


e Security components deal with aspects such as authentication, 
authorisation and access control to the rest of the components. 
The security is addressed on several levels: the security of the 
smart tags is ensured with Ciphertext Policy Attribute Based En- 
cryption (CP-ABE) by embedding policy contained in the ciphered 
tag in order to enforce access control policies associated with the 
different users; the security of the web platform and the APIs are 
ensured with the identity management based on credentials and 
authentication mechanism; and trustworthiness and data integri- 
ty hinge on the distributed ledger technology. 
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e Service Execution components include those that enable ex- 
ecution of services registered in the platform, as well as the 
service templates used to trigger dynamic creation of work- 
flows. The overall process allows users of the platform to is- 
sue service requests that are then processed by the platform, 
resolved in terms of sub-services that need to be "glued to- 
gether" to support the overall service request and are then 
executed. In order for this to take place, a series of reposito- 
ries are leveraged to first of all expose the services that are 
available in the platform, so they can be discovered, config- 
ured, triggered and reused appropriately. In addition, a compo- 
nent that intercepts the service requests and is able to break 
them down to services that are needed are involved (Service 
Manager). The service templates guide this process of identi- 


Table 4.1 Integration Strategies 


loT Platform Components developed from 
scratch and TagltSmart 
implemented and tailored to a 
specific implementation of an loT 
Platform. 


TagltSmart 


TagltSmart integrated as a 
component in a third party loT 
Platform. Infrastructure needs are 
handled by the host platform. 


TagltSmart implemented 
and deployed separately and 
3 TagltSmart integrated as needed with 

loT > different third party platforms 
bu through the open API. 
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fying what a service request needs in terms of sub-services 
as well user information. The latter both for making sure that 
only authorised users are allowed to access the platform and 
issue service requests as well as be served through the plat- 
form (e.g. an FC-scanner user to be able to use a decoding or 
stream processing component that is hosted in the TagltSmart 
platform) but also for identifying appropriate resources based 
on ownership, location and other availability criteria that need 
to be involved during a service request execution. Eventually 
the runtime execution of a service is undertaken by the Work- 
flow Enforcer, which acts as aa “middle man” between com- 
ponents, passing information between components appropri- 
ately and handling errors so that other components can focus 
solely on their functional operation. 

e Data Processing components provide additional functionality 
to handle and work with the data generated in the platform. 

e SmartTags components facilitate integration, creation and 
scanning of the SmartTags. 

e Data Access components provide the corresponding regis- 
tries, semantic models and repositories on which TagltSmart 
Operates. 


At the Virtual Entity level, the actual representations of the ob- 
jects that are part of the platform provide access to their data and 
defined actions based on the semantic models. 

Taking the architecture described above as the starting point, 
here we describe how TagltSmart functionality can be implemented 
in practice: 

Full Implementation of an loT Platform with TagltSmart: this sce- 
nario builds up from scratch all the components defined in the ar- 
chitecture of TagltSmart the functionality is integrated in the same 
codebase. The infrastructure needed to support the platform is provi- 
sioned by the implementation provider. 
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Hosted in a third party loT platform: this scenario integrates 
TagltSmart functionality in an already existing loT platform. Compo- 
nents implementation might need some adaptation to comply with the 
existing platform, yet they should be interoperable by following the 
correspondent API. Infrastructure needs are set up by the third party 
loT platform provider. 

Shared and hosted externally: this scenario considers TagltSmart 
as a standalone set of services that expose an open АР! and that can 
be accessed from different platforms simultaneously. Deployment and 
infrastructure needs are handled independently from the loT Platform. 

The components defined in Figure 4.12. are the set of compo- 
nents needed to fulfil the requirements extracted from the different 
use cases, while enabling creation and lifecycle management of the 
SmartTags. Based on the chosen integration strategy, mapping of 
some of the components to real implementations and deployments in 
a specific loT platform will be different. 


Table 4.2. TagltSmart APIs example 


This method is used to activate 


SmartTa POST 
T : the SmartTag to be enable it 
activation /product/set-smart-tag-date А 
use іп the system. 
This method is used to POST 
the location where the product 
SmartTag POST was scanned and returns all 
scan /product/product-context related context for the product 
including reviews and sensor 
states. 
Thi thod i t t 
SmartTag POST /recycl3r/api/v1/ л 
з: information about sorting and 
recycle recycling_info 


location for product recycling. 


61 lo T-EPI PROJECTS APPROACHES ADDRESSING IOT PLATFORMS INTEROPERABILITY 


As stated above, TagltSmart components define a common set of 
API methods to guarantee interoperability and seamless integration, 
as well as enabling creation of the third-party applications on top of 
its components (Table 4.1). 


VICINITY 


The VICINITY project is built around the concept of connecting dif- 
ferent loT ecosystems through the VICINITY platform (interopera- 
bility as a service), which enables to interact with loT objects from 
other different ecosystems as if they were their own. The interop- 
erability services create an environment where value-added ser- 
vices can be deployed and processes make available cross-domain 
information. 

In the presented figure, two separate ecosystems are present- 
ed: intelligent building and energy ecosystem. Each of these eco- 


Figure 4.13. VICINITY Concept 
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Figure 4.14. VICINITY Semantic interoperability approach 


systems is integrated into VICINITY by its VICINITY Adapter through 
the VICINITY Gateway. Based on the setup of virtual neighbourhoods 
in the VICINITY Neighbourhood manager, VICINITY Adapters may ac- 
cess remote loT objects based on semantic interoperability, for ex- 
ample a battery in an Energy ecosystem, and use them as a part of 
their ecosystem. Moreover, loT objects shared by the VICINITY Adapt- 
er within a virtual neighbourhood may be accessed by value-added 
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Figure 4.15. Semantic interoperability approach for Discovery 


services to provide cross-domain services using a common VICINITY 
ontology. 

One of the main challenges of implementing interoperability in 
the loT context is to enable consumers to discover, in a distributed and 
dynamic scenario, those loT objects that are relevant to their needs 
but without having any prior knowledge about them. The VICINITY 
cross-domain interoperability relies on: 


ADVANCING loT PLATFORMS INTEROPERABILITY 64 


0с 
Virtual | includes + 
'-»| TDp 


: aware of 


© | (through 


: Discovery) 


: Consumed 
GW.getPropertyValue ("TD, uuid", "position"); 


GW.getPropertyValue ("ТО uuid", "temp"); 


Figure 4.16. Semantic interoperability approach for Access 


e The VICINITY ontology’? as the common and abstract informa- 
tion model to be used; 

e The Semantic agent platform as the semantic repository. The 
W3C Web of Things Thing Description (TD) is the framework 
to be used for describing any loT object integrated in VICINITY; 


19: http://vicinity.iot.linkeddata.es/ 
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* Gateway Adapter APIs are the semantic mediators between 
the actual consumers, e.g., Adapters, and the repository of 
Thing Descriptions (TDs). Therefore, they provide an interface 
for discovery requests; 

e Gateway Adapter APIs must be able to specify discovery needs 
as semantic-based search criteria (SPARQL query). 


The first goal of semantic interoperability in VICINITY is to se- 
curely discover loT objects. A discovery search initiated on a VICIN- 
ITY Node through the Gateway API is performed in the Thing De- 
scription repository and constrained by the current setup virtual 
neighbourhood in the Neighbourhood Manager (discovered loT ob- 
jects are filtered by access rules defined on the virtual neighbour- 
hood manager). 

The second goal of semantic interoperability in VICINITY is to 
enable accessing to heterogeneous loT objects in such a way that 
any of their interaction resources can be effectively consumed after 
they were discovered. Based on the result of the discovery process, 
loT objects are accessed directly in the P2P network or through 
the Communication server services sending consumption request 
messages. 

The Gateway АР! processes response messages separately 
and applies the corresponding access mappings specified in the 
previously given Virtual TED. For each response and after the data 
lifting process is completed, the Gateway API extracts the property 
value by querying the just lifted semantic data. Finally, the Gateway 
API returns each result obtained and represented in the common 
VICINITY format. 

Used approach to semantic interoperability: Core Information 
Model with Extensions. 


Taylor & Francis 
Taylor & Francis Group 


http://taylorandfrancis.com 


Advancing loT platforms 
interoperability 


The loT-EPI efforts towards providing a framework for loT platforms 
interoperability have already provided new advanced loT platforms 
interoperability mechanisms and approaches. In this context, several 
interoperability gaps have been identified, that require further investi- 
gation and future research efforts. 

Internet of Things (loT) environments are rather complex with 
heterogeneous physical devices supporting various communication 
protocols, while they are possibly connected to an intermediary gate- 
way and then to their virtual representations (i.e. services) running 
on different platforms. Thus, it is possible to interact with a single loT 
device in many ways using its varied interfaces and representations. 

loT platforms require interoperability on multiple levels, which 
means finding the characteristic functionalities of each layer and de- 
fining meta-protocols that can be mapped on the ones used in the 
platforms (i.e. on the level of syntactic interoperability, the charac- 
teristic functionality is resource access). Resource access is real- 
ised through different protocols, for example O-MI, REST-based with 
JavaScript Online Notation (JSON) based on the W3C Web of Things 
(WoT) Description, OData-like and so on. While the functionality the 
protocols provide is basically the same (e.g. get/set/update/subscribe 
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to a resource identified by some kind of identifier), the resource dis- 
covery functionality must be addressed across protocols. 

Research on a layer-oriented approach is required to address 
providing tighter interoperability at all layers of loT systems (device, 
network, middleware, application, data and semantics) with a strong 
focus on guaranteeing trust, privacy and security aspects within this 
interoperability. This interoperability approach also provides modules 
covering quality of service (QoS) and device management, service in- 
tegration, external system services, storage and virtualisation. 

Regarding semantic interoperability, current work focuses on de- 
fining and standardizing common vocabularies in given domains (e.g. 
iot.schema.org). Interesting direction is also the effort towards do- 
main-agnostic aspects of any loT object, following the WoT approach 
(with interaction patterns, links and security). However, standard- 
ization of models is not always a viable option. Therefore, research 
should also focus on techniques that enable semantic interoperability 
even if different information models are used like semantic mapping. 

Layered approaches for interoperability allow the stakeholders 
or platform operators to select the best mechanism for interopera- 
tion. Management of such options provides coordination between lay- 
ers, enhances cooperative solutions (e.g. gateways and network) and 
enables security management. 

With regard to gateway interoperability, the inclusion of a pro- 
grammable network layer based on software-defined networking 
(SDN)/network functions virtualisation (NFV) is critical for merging loT 
and 5G and following the existing architectures. Using a programma- 
ble network has two advantages: management of mobility and man- 
agement of QoS for massive lol management. 

The most promising aspects of a common framework for loT in- 
teroperability are finding common approaches to resource access, re- 
source discovery as well as semantic interoperability. 

Further research is needed to address interoperability in the sys- 
tems-of-systems view where all devices, ‘things’ and other informa- 
tion systems should be able to interoperate at the level of Internet 
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protocols (TCP/IP, etc.) or even at the World Wide Web (WWW) level 
(HTTP WebSockets, etc.). This signifies that lower-level protocols (Zig- 
bee, LoRa, etc.) are abstracted away behind ‘wrappers’ and services 
using a limited set of loT standards. 

All loT applications need to cope with the complex nature and 
sustainability requirements of interoperability in the loT. For this, a 
framework 15 required for sustainable interoperability that especially 
targets the specific characteristics and constraints of the loT. 

A possible framework for sustainable interoperability in the loT 
should be able to address the following aspects: 


• Scalability management of interoperability in the loT: to cor- 
rectly support interoperability in the loT, interoperability re- 
sources must be efficiently and effectively managed. 

e Capacity of interoperability measurement in the loT: to prop- 
erly manage and execute interoperability in the loT, a method 
must be reached to quantify and/or qualify the interoperability 
itself. 

e Dynamic interoperability techniques and methodologies for 
the loT: to achieve enduring interoperability in the complex loT 
ecosystem, ‘things’ must be permitted to enter and dynamical- 
ly interoperate without the need for heavy modification. 


The validation aspect is very important in interoperability in gen- 
eral and even more so for the loT. Testing and validating assert that in- 
teroperability methods, protocols and so on can cope with the specific 
nature and requirements of the loT. We need to provide efficient and 
accurate test suites and an associated interoperability testing meth- 
odology that helps in testing thoroughly both the underlying protocols 
used by interconnected ‘things, machines and smart objects, and the 
embedded services and applications. In this view, we have to consider 
that to most of the existing testing methods, interconnected 'resourc- 
es’ in the loT are naturally distributed. As they are distributed, the 
usual and classical approach of a single centralised testing system 
dealing with all these components and the test execution is no longer 
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applicable. The distributed nature of the tested components requires 
moving towards distributed testing methods. 

The loT research community has to agree on data sets for eval- 
uating loT platform ingestion performance, as well as agree on sets 
of real-time queries for evaluating an loT platform digestion per- 
formance. Testing/experiment sequences have to be made explic- 
it, transparent and consensus-based to ensure a fair and unbiased 
benchmarking process. 

Implementation of the interoperability solutions should aim for 
an open source approach using different business models. The solu- 
tions need to be sustainable even after the end of the projects. Fur- 
ther research should focus on the key aspect of API homogenisation 
between platforms and federation authentication. This should allow 
for flexible cross-domain/cross-platform business process creation. 

Utilising loT (platform) technology for handling automated com- 
plex systems is a key challenge for the future. In this context, complex 
systems relate to systems that are heavily composed of rich sensing 
capabilities (e.g. radar, visual) and advanced actuation (e.g. controlling 
robot arms). The automation of these complex systems requires intel- 
ligent sensor data processing and reasoning to meaningfully control 
the actuation. loT platform technology has the potential to facilitate and 
enhance the creation of systems significantly by being the interopera- 
ble interface within and between complex systems and the automation. 
Sensors, actuators and ‘things’ description formats, communication 
protocols and APIs defined by the loT community need to use a lingua 
franca to enable such intelligent processing and reasoning. 

Examples for such automated complex systems where loT plat- 
form technology can provide a drastic development boost range from 
connected robots and robotic ecosystems over automated manufac- 
turing lines that are integrated with logistic chains to automated vehi- 
cles (ships, aircrafts, trains, trucks, cars) and fleets. 

Connecting components and systems to more complex systems 
is becoming possible with loT platform technology. Thereby, intelligent 
and automated collaboration within and between such complex sys- 
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tems will be a central challenge. Automatically creating compositions 
of loT components out of a pool of existing components (populated 
via a repository) will increase economic impact because reusing the 
components in multiple compositions will increase revenue created. 
Instead of controlling the composition centrally, it will be organised 
decentralised through intelligent choreographies. 

In the future, complex services might even be created on the fly, 
for example when a car arrives in a new city and needs a specific 
service from the city’s loT ecosystem. How such context-based ser- 
vice composition can be implemented efficiently is one of the core 
research topics that requires further study. 

Current efforts on semantic interoperability in the context of loT 
focus on ‘interoperability by standardization’ trying to define standard- 
ized vocabularies to be used by multiple platforms and thus establish- 
ing semantic interoperability. However, there always will be scenarios 
where standardization is not desired or not even possible. To provide 
semantic interoperability in these cases other approaches to seman- 
tic interoperability are needed. The most prominent and promising is 
using data and query translation based on semantic mappings be- 
tween the different information models used by the platforms. How- 
ever, since the semantic mapping technologies are not trivial tools 
that would significantly make easier the process are required. 

The unique identity of ‘things’ that spans across all platforms is 
still an unresolved issue. For instance, a car can be identified by a se- 
rial number or vehicle identification number (VIN), registration plate 
number, insurance number or some other identifier. The most appro- 
priate one might depend on the usage context, so this feature should 
be a requirement for any loT information system. 

Although there are multiple ways of assigning identity to each 
individual ‘thing’ and each individual item, the work on aligning these 
different identity approaches and enabling their mapping to allow 
easy use of the same ‘thing’ in different environments has to continue. 

The research work on a common loT interoperability framework 
needs to be continued and requires a detailed and broad analysis of 
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the different interoperability levels and their protocols paired with in- 
tensive scientific research as well as standardisation work. 

A roadmap regarding interoperability is linked with the creation 
of the loT ecosystems mainly with developers around the existing 
solutions (i.e. loT-EPI). The functionalities of the interoperability solu- 
tions must be extended, including self-* mechanisms for controlling 
actuation, especially in future loT autonomous systems. 
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Аппех 


The following section captures the different platforms the loT-EPI 
projects are utilizing in their project. 


The purpose is to present the current state of play and to geta 
nover view of for the diversity and overlap of loT platforms across the 


seven emerging ecosystems. 


The analysis briefly introduces the loT platform name, whether 
the platform is commercial or not and provides a brief description of 


its main purpose. 


A 


AGILE 


loT platform Nature of platform Brief description 


Resin.io Commercial 


Device management platform for Linux based loT 
devices. It makes it simple to deploy, update, and 
maintain code running on remote devices. 


Eclipse loT Open source 


Eclipse loT provides the technology needed to build 
loT Devices, Gateways, and Cloud Platforms. It also 
provides open source implementations for loT 
standards such as MQTT, CoAP, L:WM2M, OneM2M, 
OPC-UA and more. 


NodeRED Open source 


Tool for wiring together hardware devices, APIs 
and online services in new and interesting way. loT 
service enablement platform developed by IBM. 
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BIG loT 


loT platform Nature of platform Brief description 


Smart Data Open source CSI Piemonte's Smart Data Platform (SDP) is 

Platform a self-service platform enabling application 
development based on Internet of Things and 
Big Data [27]. SDP is based on project Yucca 
which allows for interconnecting applications, 
social networks, systems and distributed 
objects and collecting data and information, 
by processing and analysing them to develop 
end-to-end solutions 


Smart City Commercial, Bosch Considering solutions for Smart Cities, the 

Platform requirements differ from those known for 
classical enterprise applications. In fact, Smart 
City installations are composed of many 
different solutions individually customized 
for the city, but with a common need w.r.t. 
operation, data sharing and security. The 
Smart City platform (SCP) targets to connect 
the silos in the Smart City, i.e., governance, 
mobility, energy, environment, industry life, 
tourism, etc. Bosch SCP offers tools and 
methods to develop, operate and maintain 
such systems without sacrificing data security 
and privacy. 

Wubby Platform Commercial, Econais Wubby is an ecosystem of software 
components and services for rapid 
development of everyday objects [28]. 
Everyday objects are physical objects 
embedded with electronics, software, sensors 
and network connectivity to collect and 
exchange data. 


OpenloT Open Source OpenloT is a sensor middleware platform 

Platform that eases the collection of data from 
heterogeneous sensors, while ensuring their 
semantic annotations [29]. It enables semantic 
interoperability in the cloud and provides loT 
app development tools. 
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Traffic 
Information 
Centre Platform 


Bitcarrier/ 
Sensefield/ 
FastPrk 


BEZIRK 
Platform 


Commercial, VMZ 


Commercial, World 
Sensing 


Open Source 


The TIC mobility platform provided by VMZ 
is a data and service platform that has 

been developed to provide comprehensive 
information on all mobility options available 
in Berlin [30]. The platform includes real- 
time data from the traffic information 
center, mobility operators and infrastructure 
providers and provides a multimodal routing 
platform using the modal router offered by 
third parties. 


Worldsensing provides a unique traffic 
management portfolio for Smart Cities that 
includes Bitcarrier, a real-time intelligent 
traffic management and information 
solution designed for both road and urban 
environments [31]. Fastprk provides an 
intelligent parking system and Sensefields 
provides an innovative system for detecting 
and monitoring vehicles and traffic flow. 


Bosch's Bezirk platform is a peer-to-peer 
loT middleware for both communication 
and service execution on local devices 
following the service-oriented paradigm. 
Bezirk is developed with a view to facilitate 
asynchronous interactions between the 
different components of an application 
with respect to distribution across different 


devices in a network. 
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BioTope 
loT platform Nature of platform Brief description 
O-MI/O-DF Open source Implementation of O-MI and O-DF standards 
Reference for the loT that makes it easy to set up 
Implementation standard-based loT node instances. Mainly 


used for “sandbox” installations but can be 

scaled up for "industry-level" purposes. 

DIALOG Open source loT Middleware originally developed by Aalto 
in 2001, which has been further developed 
and used in numerous research projects as 
well as industrial pilots. 


NodeRED Open source Tool for wiring together hardware devices, 
APIs and online services in new and 
interesting way. Visual loT service enablement 


platform developed by IBM. 


Warp 10 Open source Platform for storage, management and 
analysis of loT data, especially for Geo Time 
Series. 

FIWARE Open source FIWARE is a middleware platform for the 


development and global deployment of 
applications for Future Internet. It is an 
outcome of a large investment of the EU into 
large-scale research programme involving 
network vendors and operators. 


Open loT Open source OpenloT is a sensor middleware platform 
that eases the collection of data from 
heterogeneous sensors, while ensuring their 
semantic annotations. It enables semantic 
interoperability in the cloud and provides loT 
app development tools. 


Mist Closed-source Software stack for distributed, secure loT 
deployments of ControlThings. 


eAir web Closed-source Cloud service for remote use and 
management of Enervent Air Handling units. 
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Оїһег 


Open/Closedsource 


Numerous platforms such as BMW's 
platform, several Smart Parking platforms in 
Helsinki, OpenDataSoft's platform. Estimated 
over 10 different platforms used now or in 


the future. 
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INTER-loT 
loT platform Nature of platform Brief description 
SEAMS EU project Smart, Energy-Efficient and Adaptive 


Management Platform (SEAMS) is a state-of- 
the art prototype-monitoring tool developed 
and implemented within the framework of the 
European project SEA TERMINALS at Noatum 
Container Terminal Valencia. The SEAMS 
platform prototype is capable of monitoring 
the machines and equipment that are being 
used at a Port Container Terminal. 


I3WSN Academic platform Industrial Intelligent Wireless Sensor 
Networks for indoor environments, platform 
developed by Universitat Politécnica de 
Valencia 


Unical BodyCloud Open source BodyCloud is an open platform for the 
integration of BSNs with a Cloud Platform- 
as-a-Service (PaaS) infrastructure and it's 
currently based on Google App Engine. 


NodeRED Open source Tool for wiring together hardware devices, 
APIs and online services in new and 
interesting way. We will use it in the AS2AS 
interoperability framework 


OpenloT Open source OpenloT is a sensor middleware platform 
that eases the collection of data from 
heterogeneous sensors, while ensuring their 
semantic annotations. It enables semantic 
interoperability in the cloud and provides loT 
app development tools. 


FIWARE Open source FIWARE is a middleware platform for the 
development and global deployment of 
applications for Future Internet. It is an 
outcome of a large investment of the EU into 
large-scale research programme involving 
network vendors and operators. 
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UniversAAL 


Eclipse ОМ2М 


WSO2 


Microsoft Azure 
loT Suite 


Amazon AWS 
loT 


Open Source 


Open Source 


Open Source ASL2.0 


Proprietary Microsoft 


Proprietary Amazon 


UniversAAL is an loT platform developed in 
the framework of an FP7 project and applied 
currently in different AAL, eHealth and AHA 
environments. 


The Eclipse OM2M project, initiated by LAAS- 
CNRS, is an open source implementation of 
oneM2M and SmartM2M standard. 


WS02 loT Server enables device 
manufacturers and enterprises to connect 
and manage their devices, build apps, manage 
events, secure devices and data, and visualize 
sensor data in a scalable manner. 


Microsoft Azure is a full cloud-based 
platform with loT specific components to 
support connection of devices to the cloud, 
analyse, store and visualize captured data. 
Microsoft Azure Suite provides an easy to 
configure back-end for loT deployments. It 
is domain agnostic and provides no models 
for data. It can be combined with advanced 
data analytics, machine learning and other 
components. 


AWS module specially intended to loT 
systems [32]. It enables a straightforward 
access to Amazon Cloud thanks to an easy to 
use management interface and a REST API 


to control the status of the things connected. 
Once data is sent to the AWS loT, then it 

can be used the huge ecosystem of AWS 
cloud solutions. This platform is completely 
domain agnostic and provides a strong 
security protection. 
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TagltSmart 
loT platform Nature of platform 


SocloTal Open source 


Brief description 


Community loT platform with privacy aware 
data sharing. Developed by the FP7 SOCIATAL 
project. 


FIWARE Open Source 


FIWARE is a middleware platform for the 
development and global deployment of 
applications for Future Internet. It is an 
outcome of a large investment of the EU into 
large-scale research programme involving 
many network vendors and operators. 


EVRYTHNG Commercial 


loT Smart product platforms. The platform 
collects, manages and applies real-time data 
from smart products and smart packaging to 
drive loT applications. 


RunMyProcess Commercial 


Microsoft Azure Commercial 


Build device independent, connected 
applications with strong business process 
integration; Deploy systems at global scale; 
Run secure, reliable and scalable operations. 
Thousands of pre-built connectors to quickly 
integrate loT-enabled devices, cloud services, 
and social media with on premise enterprise 
applications and systems. 


Full cloud-based platform with loT specific 
components to support connection of devices 
to the cloud, analyse, store and visualize 
captured data. Can be combined with 
advanced data analytics, machine learning 
and other components. 
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symbioTe 
loT platform 


OpenloT 


Symphony 


Mobility 
Back-end 
as a Service 
(MoBaaS) 


nAssist 


Navigo 
Digitale loT 
platform 


Nature of platform 


Open source 


Commercial, 
Nextworks 


Commercial, 
Ubiwhere 


Commercial, Sensing 
and Control Systems 
S.L. 


Commercial, Navigo 


Brief description 


OpenloT is a sensor middleware platform 
that eases the collection of data from 
heterogeneous sensors, while ensuring their 
semantic annotations. It enables semantic 
interoperability in the cloud and provides loT 
app development tools. 


Networks platform for the integration of home 
and building control systems. Symphony can 
monitor, supervise and control many different 
building systems, devices, controllers and 
networks available from third-party suppliers. 
It is a service-oriented middleware, able to 
integrate several functional subsystems into a 
unified IP based platform. 


System integration platform to wrap around 
different city data sources. Application 
enablement environment geared towards 
smart city apps focusing on transport and 
mobility aspects of cities. 


A software platform designed and conceived 
to allow agile, continuous management of 
data in the fields of energy efficiency, security 
and automation. Cloud-based communication 
software that enables clients to easily and 
intelligently connect machines and devices 

to the cloud and then process, transform, 
organize and store machine and sensor data. 


A vertical loT platform created to manage 
digital assets pertaining to harbours used for 
boating and yachting. Its focus is to provide 
services to the harbour's activities (B2B) and 
to its end-users (B2C). 
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KIOLA Commercial, A mobile health data collection and online 
AIT therapy management system. It integrates 

different sensor devices on the client side 
and provides backend interfaces for health 


management systems. 
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loT platform Nature of platform 


LinkSmart Open source 


Brief description 


loT middleware originally developed in 

the Hydra project. It allows developers to 
incorporate heterogeneous physical devices 
into their applications through easy-to-use 
web services for controlling any device. 


loTivity Open Source 


SiteWhere Open Source 


Eclipse Kura Open Source 


loTivity is an open source software framework 
enabling seamless device-to-device 
connectivity to address the emerging needs of 
the Internet of Things. 


The Open Platform for the Internet of Things 
provides a set of APIs to connect devices 
through MQTT, AMQP, Stomp and other 
protocols, enabling self-registration of devices 
and manipulation with devices using batches. 


Eclipse Kura is Java/OSGi-based framework 
for loT gateways including a set of APIs to 
access to hardware in/outputs, management 
of network configurations, communication 
with M2M/loT Integration Platforms. Moreover, 
Eclipse Kura supports Apache Camel routes 
to introduce business logic on the level of the 
loT gateway. 


TinyMesh Commercial 


Gorenje Cloud Commercial 
services 


Self-managed and self-healing mesh network 
platform for TinyMesh compatible devices 
that enables the collection of measures and 


performance in the network. 


Cloud based loT platform to control and 
maintain Gorenje household appliances. 


Taylor & Francis 
Taylor & Francis Group 


http://taylorandfrancis.com 
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